Report

Resumen ejecutivo

La intención de este documento es mostrar cómo se han organizado los conocimientos compartidos en la base de conocimiento común con los compañeros.

Enlace

ISPP 23-24 BGCC

Semana 1

Feedback específico del equipo

Feedback general

• La importancia de resaltar la idea principal de lo que se quiere transmitir. Cuál era el propósito de la aplicación, etc. El objetivo de esta semana era conocer la idea, analizar qué es lo que nos interesa y cómo lo vamos a llevar a cabo.

• El feedback de los compañeros es importante, indica que se enteran de la presentación.

Presentación

• Respecto a la parte visual, las diapositivas están muy bien, pero faltan los números de página.

• Utilizar nuestros propios conceptos, no los de la asignatura.

• Presentaciones más visuales para que sean más dinámicas.

• Evitar usar imágenes que "creamos que no se ven bien".

• Plantear mejor cómo presentar el cuadrante de crecimiento de competidores. Mejor una imagen creada por nosotros que una captura.

• Eficiencia de la comunicación: intentar buscar lo que resulta valioso. Pensar en la cantidad de información que se proporciona (los árboles te impiden ver el bosque).

• A veces se ha hablado muy rápido y cuesta seguir el ritmo.

• Preparar mejor el discurso de las presentaciones.

• Presentar un reloj de horas totales. Cada semana se actualiza el tiempo consumido.

Base de conocimiento

• ¿Almacenamiento organizado de la información? Tenemos que pensar qué consultas vamos a hacerle a la base de conocimiento para aclarar qué herramienta utilizar.

• Guardar todos los enlaces de los diálogos con la IA.

Feedback común

Acuerdo de compromiso

• El commitment agreement tiene que estar desarrollado y firmado. Comentar cada semana si se ha tenido que ejecutar alguna cláusula o no.

Análisis de costes

• Hay que distinguir entre el coste de la puesta en marcha y el del mantenimiento. El dato verdaderamente importante es aventurar cuánto va a ser el coste mensual una vez se haya puesto en marcha el proyecto.

Presentación

• Añadir las estadísticas de uso de las herramientas y tecnologías.

• Reloj del proyecto. Todas las presentaciones deben tener un reloj del proyecto, debe estar iniciado con 150h*X personas. Cada semana se incrementa, debe aparecer el bloque total de horas que debe coincidir con el Clockify.

• En cada semana mostrar el incremento de mejora, qué ha cambiado.

• Esta semana era el momento de focalizarse en los casos principales. Hay que ser originales.

• Menos, es más. Una imagen dice más que mil palabras.

• Hilo argumental. Dar importancia a los verdaderamente crítico. Donde está la mayor debilidad.

• Pensar si lo que estamos ofreciendo es un producto o un servicio.

• Tooling support dashboard, hacer un cuadro de estadísticas en el que se vea el uso real de cada una de las herramientas del proyecto.

Presentadores

• La velocidad de exposición genera que no se pueda dar un feedback preciso. Intentar ser eficientes. Plantearse qué es lo que se quiere transmitir en la presentación.

Semana 2

Feedback específico del equipo

Feedback general

• Antonio estaría dispuesto a pagar por nuestra aplicación. Quiere un asistente que le diga cuántos aparcamientos hay en su cercanía y le guíe. Que se pueda hablar con un asistente, para que no haya que manipular.

• Müller propone: ceder el aparcamiento. Que se cedan las plazas. Hacer que se espere la persona que libera el aparcamiento a que llegue el que la solicitó.

• Descartar la idea de los parkings privados. Eso lo tiene Google mejor.

Presentación

• A la hora de exponer, mirar a todos, exponer de forma en la que captamos la atención, hacer comentarios graciosos y sarcásticos para que no sea monótona la presentación. Contar un ejemplo y/o una historia breve.

• Killer opener: una historia para enlazarla con la presentación.

• Para datos estadísticos mejor citar fuente.

• Hay que dejar los datos de contacto y el QR de feedback en las próximas presentaciones, durante todo el momento de preguntas y feedback.

Herramientas

• Usar copilot y ahorrar tiempo. Ya que hay herramientas hay que usarlas.

• “Torpes sois si no usáis ChatGPT para programar” - Antonio.

Riesgos

• Los riesgos con más probabilidad hay que pensar en los planes de contingencia bien.

Feedback común

Acuerdo de compromiso

• No vale solo un documento hecho con ChatGPT, tiene que estar más elaborado.

Presentación

• Hay palabras que no se deben utilizar a no ser que sea requerido por el contexto ya que puede dar a entender otra cosa.

• Añadir un símbolo como una “F” para indicar que ese apartado se ha arreglado gracias al feedback.

Semana 3

Feedback específico del grupo

Presentación

• Poner los planes de precio de la aplicación.

• Más zoom en los mockups, hay que buscar la manera en la que el móvil se vea bien.

Presentadores

• Usar lenguaje más formal, dejar atrás tantas coletillas.

• Micro más lejos si se habla fuerte.

• Usar los términos ingenieriles, profesionalizar el vocabulario.

Análisis de costes

• Barajar ingresos por anuncios, al principio con bajos.

Competidores

• Actualizar los competidores, echar un ojo constantemente.

• Adaptar las nuevas características de Apparkya a las funcionalidades de nuestra página.

Usuarios piloto

• Gestión de usuarios pilotos, hay que contactar con ello, empezar a hablar con los del grupo 5 y buscar gente externa dispuesta a usar la aplicación.

• Crear un plan de gestión de las comunicaciones.

Feedback común

Acuerdo de compromiso

• Mostrar y actualizar el estado del commitment agreement.

• Presentación

• Evitar usar frases de más de 3 palabras, buscar adjetivos. Síntesis de la información.

• Hay que hablar de los problemas en las presentaciones para poder recibir soluciones.

• Al final de la presentación hacer una autodefensa.

Presentadores

• Antes de la presentación hacer una reunión donde los demás del grupo escuchan como presentan sus compañeros y dadle feedback para mejorar de cara a la clase. Proponen usar una IA que transcriba lo que dicen y pedir a ChatGPT después que mejore el guion y lo sintetice.

Semana 4

Feedback específico del grupo

Desarrollo

• Hay que mejorar la forma de hacer tests, que el testeo lo haga otra persona diferente a quien haga la funcionalidad. Hay que seguir las buenas prácticas.

• Añadir comentarios en tareas para github, no le estamos sacando partido al potencial que eso tiene. En la propia issue se declara el caso de uso que la implementación debe superar. Mirar el número de comentarios por issue como forma de media; a semana que viene nos preguntaran por esto.

Commitment agreement

• Añadir estado del commitment agreement para la siguiente presentación.

Spring Backlog

• Indicar hacia donde se quiere llegar en los 3 springs.

Riesgos

• Indicar si se han solventado los riesgos que están ocurriendo y como se han solventado.

• Tenemos que saber identificar cuáles son los puntos de bloqueo, hay que identificar las razones por las que el proyecto se puede quedar bloqueado.

Costes

• Tener en cuenta el marco temporal y la "capacidad nominada" del opex ¿Si se duplica el número de usuarios, se dobla el coste? ¿Se triplica?

Presentación

• No tenemos que demostrar que hemos hecho las cosas mal, hay que mirar las soluciones.

• No hacer referencias a otras presentaciones que hemos hecho.

• Ha faltado: elevator speech, mvp, casos de uso y explicar de dónde viene las fórmulas.

Feedback común

Acuerdo de compromiso

• Debe de haber cabida a que no todo el mundo en el equipo quiera un 10.

• Debe de haber los anexos del número de horas que invierte cada uno y quienes son los responsables de cada tarea. Antonio sugiere poner un enlace a la issues de github.

• Se debe poner como anexo todos los documentos en los que se dice que aplica el commitment agreement.

Análisis de costes

• Ver de qué manera evoluciona el TCO ¿más usuarios más costos de operación?

Gestión de código

• Usar las issues de github para comunicarse con los demás integrantes sobre las tareas. Hay que poner comentarios en las issues de los demás.

Presentación

• Mostrar en la presentación el rendimiento y la evolución de los integrantes.

• No olvidar el elevator speech.

• Mostar el MVP, su utilidad es ver aquello que en general le da valor al negocio y va a hacer que el producto tenga éxito.

• Hablar del costumer agreement.

Usuarios pilotos

• Usar iTop para tener el feedback de los usuarios pilotos es una buena idea.

Semana 5

Feedback específico del grupo

Aplicación

• Para el tamaño del parking poner algún tipo de medida. Por ejemplo algún coche como medida.

Costes

• Ir actualizando los costes con las horas que llevamos.
• Calcular los beneficios y gastos optimistas, pesimistas y esperados.
• No juntar TCO y Mantenimiento.

Presentación

• Presentar la situcación altual de los costes, cuanto llevamos gastado.
• Dejar muy claro en la presentación el rendimiento del equipo y el estado del comitmment agreement. Deben estar separados.
• Presentar el objetivo de los 3 sprint.
• Presentar tablas más claras que indique que es cada columna/fila.

Riesgos

• Muy buena manera de presentar los riesgos.

Herramientas

• Descargarse el pluging de Clockify, muy util para contavilizar el tiemo en el github.

Feedback común

Análisis de costes

• Hacer el análisis de costes/beneficios pesimistas, optimistas y esperados.

Gestión de código

• Comentar en la issues de los compañeros. Los profesores están echando un ojo y ven pocos comentarios.
• Tener un repositorio formal. Es nuestra tarjeta de presentación.

Presentación

• TODO tiene que estar contenido en la presentación, el trabajo puede que lo corrija alguien que no ha visto la presentación.
• No hacer cambios de la presentación entregada.

Semana 7

Feedback específico del grupo

Presentación

• Importante mostra el customer agreement.
• La situcacióm actual frente al total debe ir con los costes.
• Hay que poner un video en la demo, se está vendiendo humo.

Costes/Beneficios

• Indicar en la presentacion el número de clientes estimado y de donde han salio.

Burn down

• El burn down se debe hacer por sprint, no por semana.
• Debe representar el estado en que se encuentra el sprint en el momento de la presentación.

Project management

• Se han hecho previsiones poco realistas de acuerdo con el ritmo que llevamos.

Feedback común

Análisis de costes

• El calculo del TCO hay que hacerlo a 2 años vista.

Presentación

• Usar zoom para mostra los detalles de la aplicación en la demo.
• Presentar aspectos legalres.
• Antes de poner la demo explicar que se va a ver así se puede obviar la voz en off.

Rendimiento

• Hacer una matriz Razzi para ver la relación entre el rendiemiento y el esfuerzo de los integrantes.

Usuarios pilotos

• Hay que hacer un balance entre una guía que lleve de la mano al usuario pilotti y dejarlo por libre. Se deberá decir al usuaro que testear pero tamoco explicarlo 100% como funciona para que explore y explique como de intuitivo/fácuil es hacer esa función.

Semana 8

Feedback específico del grupo

Presentación

• Relacionar el inicio efectivo con la demo.
• Mucho tiempo dedicado a la parte inicial. Se tiene que dedicar el mayor tiempo a la parte técnica y planificación del proyecto que a vender el producto.
• Explicar en la presentación como se va a gestionar el feedback de los usuarios pilotos.

Demo

• Usar una lupa en la demo para hacer zoom en las partes claves.

Documentación

• Poner las condiciones de fallo en la parte del Sprint 2, no en Planificación del proyecto.

Desarrollo

• Se valora positivamente implementar un social loging (google, facebook, ...)

Feedback común

Demos

• Usar una lupa para hacer zoom a lar partes importantes de la demo. Pero sin pasarse.

Presentación

• No usar colores con tonos similares para exponer distintas cosas en una misma gráfica/tabla.

Semana 9

Feedback específico del grupo

Demos

• Enlazar la demo con el anuncio, usar simbolos para indicar que tipo de usuario usa la funcionalidad.
• Hacer la demo con la aplicación en claro (blanco).
• Eliminar las partes que no forman parte del core de la aplicacion, como el login.

Presentación

• La parte del planning de la siguiente semana va después de la demo.
• Poner menos datos en las diapositivas porque no da tiempo a digerir la información.
• Ajustar el tamaño de las diapositivas a la pantalla donde se proyecta.
• Cuidar la presentación y unificar los estilos. Hay que ser profesionales y consistentes.
• La parte del costumer agreement se puede reducir a una diapositiva.
• Elaborar un elevator pitch que hable sobre nuestra funcionalidad de forma resumida.

Presentadores

• Vocalizar más en el inicio.
• Explicar mejor de que va nuestra aplicación para que sea clara para los oyentes.

Feedback común

Demos

• Incluir datos realistas en las demostraciones.

Presentación

• Hay que mantener la uniformidad en los elementos de las presentaciones como las gráficas.

• Mantener la misma tipografía y paleta de colores en todas las diapositivas.

• Conectar la demo con el anuncio y el inicio ejectivo.

• No añadir información excesiva en las presentaciones, que permita a los oyentes digerir la información.

• Para la información extra añadirlas a diapositivas finales después de todo por si preguntan por esa información.

Semana 10

Feedback específico del grupo

Presentación

• Hacer la gráfica de Proyect state más grande para que se aprecia mejor los datos.
• Añadir apoyo visual para el killer opener
• Explicar antes de mostrar la demo que se va a mostrar.
• Mejorar la performance-time matrix.

Riesgos

• Si un riesgo ocurre, es un problema --> PROBLEM MONITORING
• Especificar mejor las soluciones que se toman para solucionar los riesgos.
• Establecer un umbral para comprobar la eficacia de la solución al problema.

Feedback común

Análisis de costes

• Usar la palabra Incomes en vez de Benefits

Marketing

• Indicar un calendario de cuando se va a subir contenido a las rrss y de que tipo.
• Buscar la forma de captar la atención en el mercado, comprobar quiénes van a usar la app y eforcar el marketing en ese sentido.

Presentación

• Poner información en las diapositivas que concuerde con lo que se dice en la presentación. Sincronía.
• Evitar poner mucho texto.
• No meter política/religión en presentaciones técnicas.
• Seguir una historia a lo largo de toda la presetación.

Usuarios pilotos

• Hacer una encuesta a los usuarios pilotos para saber si pagaria o no por usar la app y cuánto.

Accciones de consolidacion

• Se han añadido un par de diapositivas al principio que darán un poco de contexto durante el killer opener.
• Se ha añadido una diapositiva antes de la demos que muestra que vamos a enseñar en la demo.
• Se ha cambiado la forma de representar la matriz de tiempo esfuerzo usando el mimo tipo de gráfica que usa el grupo 7.
• Se ha cambiado el titulo de la diapositiva de risk monitoring a problem monitoring.
• Se han añadido unas diapositivas que explican el plan de marketing que se está siguiendo.

Semana 11

Feedback específico del grupo

Anuncio

• Acortar el anuncio.
• No usar terminos de ingenieros en la presentación, por ejemplo C2C.
• Usar datos para convencer a los inversores, datos que llamen la atención.
• No comentar cosas irreales, aunque sea para un chiste.
• Centrarse en la funcionalidad de ceder aparcamiento.

Demo

• No incluir la introducción de datos en los formulacios (registrarse, inicio de sesión, etc.)
• Centrarse en la cesión de aparcamiento.

Presentación

• Mejorar la narrativa con la que se cuenta los competidores. Llamar más la atención a los oyentes para vender que lo nuestro es mejor.
• No destacar el paso pesimista en los costes y beneficios, a no ser que sea para realzar lo bueno.
• No poner el título de Elevator pitch.
• Hacer un Elevator pitch más impovisado, que no quede muy enconsetado y planeado.
• La parte de key aspect no es nada específica, vende humo.

Marketing

• Goals del plan de marketing muy genérico.
• Presentar el calendario de marketing y un ejemplo de flyer.

Segmentación

• Segmentación muy genérica. No vale decir que todos valen.
• Crear una persona para mostrar cual es el público objetivo.

Feedback común

Anuncios

• Anuncios cortos, máximo 25 segundos.

Demos

• Hacer demos directas, enseñando la parte nuclear de la aplicación y saltando elementos que son irelevantes.

Marketing

• Presentar planes de marketing específicos, a donde se quiere llegar y como.

Presentación

• No destacar el paso pesimista en los costes y beneficios, a no ser que sea para realzar lo bueno.
• Añadir apoyo visual en el killer opener.
• El planteamiento de esta presentación tiene que ir enfocada al evento de salir al mercado, esto significa que no se puede hacer referencia a cosas anteriores, no hablar con técnicismo, ni en el contexto de la asginatura.

Presentadores

• No usar vocabulario de la asigntura o de ingenieros. Todo el mundo debe entender de hablas en la presentación.

Segmentación del mercado

• Usar herramientas para la búsqueda de palabras claves.

Accciones de consolidacion

• Se ha creado un anuncio un poco más corto y directo que además presenta la funcionalidad de ceder aparcamiento.
• Se ha cambiado el anuncio de inversores usando un vocabulario más accesible y usando datos para atraer la atención de inversores.
• Se ha recortado de la demo la parte de rellenar datos.
• Se ha modificado la dispositiva de key aspect, mostrando las funcionalidades realistas.
• Se ha borrado el título de la dispositiva elevator pitch para hacerlo más natural.
• Se han concretado los objetivos del plan de marketing además de añadir un calendario de los posts.
• Se han creado flyers para anunciar aparking y se han añadido a la presentación.
• Se han creado dos perfiles para mostrar mejor la segmentación de mercado.

Semana 12

Feedback específico del grupo

Presentación

• No hace falta un índice que vaya siguiendo, simplemente la presentación debe seguir un hilo argumental bueno.
• Presentarse al inicio de la presentación.
• Hacer el inicio efectivo más visual, usar varias fotos que sigan la historia.
• Recortar la tabla de competidores, dejar los más relvantes o marcarlos para que destaquen.
• No usar terminos de la asignatura (CapEX, OpEX, TCO).
• Redondear los números.

Anuncio Inversores

• Añadir lo de los tipos de inversión en el anuncio de inversores y quitarlos de la presenatción.
• Dar datos reales que inciten a los usuario a invertir en la aplicación.

Demo

• Que la demo sea más como una historia, más fluido todo. Que siga el contexto del anuncio.

Presentadores

• Dar toda la energía posible para la presentación.
• Hacer una conexión fluida de los apartados.

Segmentación del mercado

• Abarcar a un rango de edad diferente o justificarlo mejor.
• Enfocar la publicidad segun al sector al que nos queremos centrar. Anucios televisión, baners, ... .

Feedback común

Anuncios

• En el anuncio de inversores añadir datos reales que llame la atencio de los inversores. Datos que respanden que la aplicación es ecalable.

Demos

• Que la demo sea fluida, como una historia siguiendo una narrativa planteada en el anuncio por ejemplo. No debe ser un listado de funcionalidades que se van probando de una en una.

Presentación

• No usar tecnicismos de la asignatura como CapEX, OpEX.
• No poner elementos que no se van a explicar. Por ejemplo una formula de la que no se va a hablar en detaller.

Accciones de consolidacion

• Se ha eliminado el indice de las diapositivas.
• Se ha modificado el inicio efectivo para la última presentación.
• En la tabla de competidores solo se ha dejado los dos más importantes. Telpark y Parkclick.
• Se ha eliminado los termino tecnicos. CapEX -> Costes de capital. OpEX -> Costes Operacionales.
• Se han cambiado el anuncio de inversores, añadiendo los tipos de inversores.
• Se ha dado más fluidez a la demo de modo que siga una historia más narrativa.
• Ensayaremos la presentacion delante de los demás integrantes del grupo para mejorar la narrativa y obtener feedback antes de la presentación final.
• Se ha cambido el plan de marketing para que también se tenga en cuenta un rango de edad más amplio, anuncios de TV, banners,... .

Plan de consolidación

Después de la presentación, nos hemos reunido todas las semanas para comentar el feedback recibido y establecer soluciones para mejorar lo comentado por los profesores tanto a nosotros como los compañeros. Se ha reforzado y animado a los compañeros a seguir con el trabajo que ha sido alabado en el feedback y se han compartido nuevas estrategias para mejorar el producto mostrado.